If left undeclared it's equivalent to Any, so adding Any doesn't give more information.

It does make a difference for BasedPyright at least. I verified, by applying the change locally in the sitepackages. BasedPyright seems to distinguish between being explicit about there not being type information and just omitting it. My guess, to prevent developers from forgetting to annotate functions. In the later case BasedPyright classifies the type as "Unknown" rather than any.

I understand the type checker behavior here, but that error exists so that you're alerted about calling functions where the type checker doesn't know the allowed argument type. Blindly adding Any makes the error go away but doesn't fix the underlying problem: we still don't know what argument types are allowed.

That said, perhaps the "true" type really can't be expressed in the type system here, in which case Any is correct. But then our policy asks that we add a comment to each Any explaining why we need it.

Added a comment motivating the Any. There might also be union which is narrow than Any. Maybe: int | float | bool | bytes | str | bytearray | list[Any] | tuple[Any, ...] | dict[str, Any] | _CDataBase | None = None

Not sure this is better though. Type checking will always be wanting in this situation, because the allowed type depends on the value of cdecl which is only known at runtime. The decision made in _cffi_backend.py seems reasonable to me.

Followed your advice and added a comment to the declaration.

Diff from mypy_primer, showing the effect of this PR on open source code:

pandas (https://github.com/pandas-dev/pandas)
- pandas/core/computation/ops.py:328: error: Need type annotation for "_binary_ops_dict" (hint: "_binary_ops_dict: dict[<type>, <type>] = ...")  [var-annotated]